AI Agent 核心概念与架构
如果说 ChatGPT 让大模型学会了"说话"，那 Agent 就是让大模型学会了"做事"。Agent 不只是回答问题——它能思考、规划、使用工具、执行动作，像一个真正的数字员工。理解 Agent 的核心架构，是 AI 产品经理把握下一波 AI 产品浪潮的必修课。
1. Agent 到底是什么
1.1 一句话定义
AI Agent = LLM + 规划能力 + 工具使用 + 记忆 + 自主执行
普通 Chatbot 是「你问我答」，Agent 是「你给目标，我自己想办法完成」。
普通 Chatbot：
用户："帮我查一下北京明天的天气" → 模型："我无法访问实时数据..."
Agent：
用户："帮我查一下北京明天的天气"
→ 思考：需要调用天气 API
→ 行动：调用 get_weather("北京", "明天")
→ 观察：返回"晴，15-25°C"
→ 回答："北京明天晴天，15-25°C，适合户外活动。"
1.2 Agent vs Chatbot vs Copilot
| 维度 | Chatbot | Copilot | Agent |
|---|---|---|---|
| 交互模式 | 你问我答 | 我建议你确认 | 你定目标我执行 |
| 工具使用 | 无 | 有限 | 丰富（搜索、API、代码执行等） |
| 自主决策 | 无 | 低 | 高 |
| 规划能力 | 无 | 无 | 有（任务拆解、多步执行） |
| 代表产品 | ChatGPT 基础版 | GitHub Copilot | Devin、Claude Code、AutoGPT |
关键判断标准：如果用户说完一句话后，系统需要自主执行多个步骤才能完成任务——那它就是 Agent。
2. Agent 四大核心组件
2.1 规划（Planning）
Agent 收到任务后的第一步：把复杂任务拆解为可执行的子任务。
任务分解示例：
用户目标："帮我分析竞品 Notion AI 的产品策略"
Agent 规划：
├── Step 1: 搜索 Notion AI 最新功能更新
├── Step 2: 搜索 Notion AI 定价策略变化
├── Step 3: 搜索用户对 Notion AI 的评价
├── Step 4: 整合信息，撰写分析报告
└── Step 5: 生成对比表格和建议
主流规划方法：
| 方法 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| ReAct | 思考→行动→观察，循环执行 | 简单可靠 | 每步都要推理，较慢 |
| Plan-and-Execute | 先生成完整计划，再逐步执行 | 效率高 | 计划可能需要动态调整 |
| Tree of Thoughts | 探索多条路径，选最优 | 推理质量高 | 计算成本高 |
2.2 记忆（Memory）
Agent 需要记住之前发生了什么，才能做出连贯的决策。
短期记忆（Working Memory）：当前对话的上下文，存在 Context Window 中。
长期记忆（Long-term Memory）：跨会话的信息，通常存储在向量数据库中。
短期记忆：用户刚才让我查了 Notion AI 的定价
长期记忆：上周用户提过他们的产品预算是 10 万/月
→ Agent 可以自动对比 Notion AI 的价格是否在预算内
2.3 工具（Tools）
工具是 Agent 与外部世界交互的接口。没有工具的 Agent 只能"想"，有了工具才能"做"。
常见工具类型：
| 工具类型 | 示例 | 对应能力 |
|---|---|---|
| 搜索 | Google Search、Bing API | 获取实时信息 |
| 代码执行 | Python 沙箱、Bash Shell | 数据计算、自动化 |
| API 调用 | Slack、GitHub、数据库 | 操作外部系统 |
| 文件操作 | 读写文件、PDF 解析 | 处理文档 |
| 浏览器 | 网页浏览、截图 | 访问网页内容 |
工具调用流程（Function Calling）：
1. 模型分析用户需求
2. 模型决定需要调用哪个工具，生成参数
3. 系统执行工具调用
4. 将工具返回结果注入上下文
5. 模型基于结果继续推理或生成回答
2.4 行动（Action）
Agent 根据规划和工具调用结果，执行具体动作并产生真实影响。
关键设计问题：哪些行动需要人类确认？
低风险（自动执行）：搜索信息、读取文件、数据分析
中风险（建议确认）：发送消息、修改文档
高风险（必须确认）：删除数据、金融交易、发布内容
3. ReAct 模式详解
ReAct（Reasoning + Acting）是目前最主流的 Agent 执行模式。
3.1 执行循环
ReAct 循环：
Thought（思考）→ Action（行动）→ Observation（观察）→ 重复直到任务完成
示例：查找某公司最新融资信息
Thought: 我需要查找这家公司的最新融资信息
Action: search("公司名 + 最新融资")
Observation: 搜索结果显示 2024 年 3 月完成 B 轮融资 5000 万美元
Thought: 我找到了融资信息，但还需要确认投资方
Action: search("公司名 + B轮 + 投资方")
Observation: 由红杉资本领投，老股东跟投
Thought: 信息已经足够完整，可以回答用户了
Answer: 该公司于 2024 年 3 月完成 B 轮融资，金额 5000 万美元，由红杉资本领投。
3.2 产品设计要点
- 思考过程是否展示给用户？ 展示可以增强信任感，但会增加视觉复杂度
- 工具调用失败怎么办？ 必须设计重试和降级策略
- 循环次数上限？ 防止 Agent 陷入无限循环（通常设 10-15 次上限）
4. 单 Agent vs 多 Agent
4.1 单 Agent
一个 Agent 处理所有任务。适合简单场景。
优点：架构简单，上下文共享自然 缺点：能力天花板低，复杂任务容易混乱
4.2 多 Agent（Agent Swarm / Multi-Agent）
多个专业化的 Agent 协作完成复杂任务。
多 Agent 协作示例：AI 产品需求评审
📋 PM Agent（产品经理）：接收需求，拆解为技术问题
🔧 Tech Agent（技术顾问）：评估技术可行性和成本
📊 Data Agent（数据分析师）：分析相关数据指标
💰 Biz Agent（商业分析师）：评估商业价值和 ROI
📋 PM Agent：汇总各方输入，生成评审报告
主流多 Agent 框架：
| 框架 | 特点 | 适合场景 |
|---|---|---|
| CrewAI | 角色定义 + 任务流程 | 团队协作模拟 |
| AutoGen (Microsoft) | 对话驱动的多 Agent | 研究探索 |
| LangGraph | 状态图驱动 | 复杂工作流 |
| Claude Code Teams | 原生多 Agent | 代码项目协作 |
4.3 选型建议
决策树：
├── 任务简单，步骤 < 5 → 单 Agent
├── 任务复杂但领域单一 → 单 Agent + 多工具
└── 任务跨领域、需要多种专业能力 → 多 Agent
5. Agent 产品案例分析
5.1 Devin（软件工程 Agent）
- 定位：自主完成编程任务的 AI 软件工程师
- 架构：规划 + 代码编辑器 + 终端 + 浏览器
- 产品洞察：不是 Copilot（建议代码），而是 Agent（独立完成任务）
- PM 启发：Agent 产品的关键不是"能做什么"，而是"做错了用户怎么纠正"
5.2 Claude Code
- 定位：终端中的 AI 编程助手，能读写文件、执行命令
- Skills 系统：用户可以安装/创建自定义能力模块
- Team 模式：多个 Agent 协作完成复杂项目
- PM 启发：Agent 的可扩展性（Skills/插件）是生态护城河
5.3 Perplexity
- 定位：AI 搜索引擎
- Agent 特征：自动搜索多个来源 → 综合分析 → 生成引用答案
- PM 启发：Agent 不一定是"全自动"——搜索+综合就已经是 Agent 模式
6. AI PM 需要关注的 Agent 产品设计要点
6.1 可观测性
用户需要理解 Agent 在做什么。设计上要展示：
- 当前步骤和进度
- 工具调用过程
- 中间结果
6.2 可控性
用户需要随时能干预。提供：
- 暂停/继续
- 修改计划
- 撤销操作
6.3 可预测性
Agent 的行为应该在用户预期范围内：
- 执行前展示计划让用户确认
- 高风险操作强制人工审批
- 设置资源消耗上限（Token、时间、API 调用次数）
核心要点
- Agent = LLM + 规划 + 工具 + 记忆 + 执行，缺一不可
- ReAct 是主流执行模式：思考→行动→观察的循环
- 工具是 Agent 的双手：没有工具调用能力的 Agent 不是真正的 Agent
- 多 Agent 适合复杂跨领域任务，但增加了协调成本
- Agent 产品设计的核心矛盾：自主性 vs 可控性——给用户安全感是第一优先级